home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 515 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.2 KB
  1. Subject: Re: read() and POSIX compliance
  2. Date: Sun, 26 Sep 93 16:47:14 CET
  3. From: Juergen Lock <nox@jelal.north.de>
  4. In-Reply-To: <9309252345.AA21917@terminator.rs.itd.umich.edu>; from "Nicholas S Castellano" at Sep 25, 93 7:45 pm
  5. Message-Id: <9309261547.AA00072@jelal.north.de>
  6.  
  7. Nicholas S Castellano writes:
  8.  
  9. > POSIX introduces the O_NONBLOCK flag which causes the read() to return
  10. > -1 with errno set to EAGAIN, when the file has no data available but
  11. > is not an end-of-file condition.
  12.  
  13.  (other names are O_NDELAY and EWOULDBLOCK...)
  14. > 
  15. > I'm thinking along these lines:
  16. >   -call Fcntl(fd, &nbytes, FIONREAD)
  17. >   -call Fread(...)
  18. >   -if Fread() returns 0:  then if nbytes is 0 return -1 with errno =
  19. >     EAGAIN, otherwise return 0 signifying end-of file.
  20. > 
  21. > This seems valid for the TOS filesystem (since it always gives 1 for
  22. > FIONREAD it will never give EAGAIN) and for the pipefs (which will
  23. > give -1 for FIONREAD at end-of-file [that is, when the other side of
  24. > the pipe is closed] and 0 if there is just no data ready).
  25. > 
  26. > This reasoning breaks down, however, in the case of a device such as
  27. > the shmfs.  This device will give 0 bytes for an FIONREAD when at
  28. > end-of-file, so using the above scheme would mean a non-blocking
  29. > read() on shmfs would never return 0.
  30.  
  31.  there's more to it...  on ttys 0 can mean no data available, it can
  32. mean `eofc read' (i.e. got ^D) and, should we get a better serial driver
  33. some day that doesn't always think its in local mode :) then it can also
  34. mean `hangup'.  the first case should become EAGAIN, the others not...
  35.  
  36.  oh and of course between FIONREAD and the actual Fread call you also
  37. have a wonderful race. :-)  i.e. whats when data becomes available just
  38. before it calls Fread...
  39. > 
  40. > I'm a bit stumped.  I think it will be necessary to define the exact
  41. > action of FIONREAD at end-of-file for device drivers in some
  42. > consistent manner in order to make it possible to distinguish EOF from
  43. > a lack of available data.
  44.  
  45.  i think the only way to get this work is change the kernel and device
  46. drivers `read' functions.  and then maybe turn EAGAIN back into 0 for
  47. TOS domain processes.
  48.  
  49.  only problem, it seems Eric never has time...
  50.  
  51.  cheers
  52.     Juergen
  53.